home *** CD-ROM | disk | FTP | other *** search
/ EuroCD 3 / EuroCD 3.iso / Programming / vbcc / doc / vbccm68k.doc < prev    next >
Text File  |  1998-06-24  |  13KB  |  299 lines
  1. vbcc - C compiler (c) in 1995-97 by Volker Barthelmann
  2.  
  3.  
  4. INTRODUCTION
  5.  
  6.     vbcc is a free portable and retargetable ANSI C compiler.
  7.     It is clearly split into a target independant and a target dependant
  8.     part and supports emulating datatypes of the target machine on any
  9.     other machine so that it is possible to e.g. make a crosscompiler for
  10.     a 64bit machine on a 32bit machine.
  11.     This document only deals with the target dependant parts of the
  12.     Amiga68k version.
  13.  
  14.  
  15. LEGAL
  16.  
  17.     vbcc is (c) in 1995-96 by Volker Barthelmann. All code is written by me
  18.     and may be freely redistributed as long as no modifications are made
  19.     and nothing is charged for it.
  20.     Non-commercial usage of vbcc is allowed without any restrictions.
  21.     Commercial usage needs my written consent.
  22.  
  23.     Sending me money, gifts, postcards etc. would of course be very nice
  24.     and may encourage further development of vbcc, but is not legally or
  25.     morally necessary to use vbcc.
  26.  
  27.  
  28. ADDITIONAL OPTIONS FOR THIS VERSION
  29.  
  30.     -cpu=n      Generate code for cpu n (e.g. -cpu=68020), default: 68000
  31.  
  32.     -fpu=n      Generate code for fpu n (e.g. -fpu=68881), default: 0
  33.  
  34.     -sd         Use small data model (see below).
  35.  
  36.     -sc         Use small code model (see below).
  37.  
  38.     -prof       Insert code for profiling (not really usable yet).
  39.  
  40.     -g          Generate debugging hunks which contain addresses of static
  41.                 objects and links assembly instructions to source lines.
  42.                 This does not work with -gas.
  43.  
  44.     -const-in-data
  45.  
  46.                 By default constant data will be placed in the code
  47.                 section (and therefore is accessable with faster pc-relative
  48.                 addressing modes). Using this option it will be placed in the
  49.                 data section.
  50.                 This could e.g. be useful if you want to use small data and
  51.                 small code, but your code gets too big with all the constant
  52.                 data.
  53.                 Note that on operating systems with memory protection this
  54.                 option will disable write-protection of constant data.
  55.  
  56.     -use-framepointer
  57.  
  58.                 By default automatic variables are addressed through a7
  59.                 instead of a5. This generates slightly better code, because
  60.                 the function entry and exit overhead is reduced and a5 can be
  61.                 used as register variable etc.
  62.                 However this may be a bit confusing when debugging and you
  63.                 can force vbcc to use a5 as a fixed framepointer.
  64.  
  65.     -no-addressing-modes
  66.  
  67.                 The intermediate code does not contain any of the 68k
  68.                 addressing modes, so if they are to be used an extra pass
  69.                 over the intermediate code is necessary to recognize certain
  70.                 patterns that can be expressed using a 68k addressing mode.
  71.                 By default vbcc tries to use some 68k addressing modes.
  72.                 Currently (ax)+ and subsets of (displ,ax,dy*skal) are used.
  73.                 However not all cases where those addressing modes could be
  74.                 used are recognized.
  75.                 With this option you can prevent vbcc from searching for
  76.                 possible addressing modes. This may simplify debugging.
  77.  
  78.     -no-delayed-popping
  79.  
  80.                 By default arguments of function calls are not always popped
  81.                 from the stack immediately after the call, so that the
  82.                 arguments of several calls may be popped at once.
  83.                 With this option vbcc can be forced to pop them after every
  84.                 function call.
  85.                 This may simplify debugging and very slightly reduce the
  86.                 stack size needed by the compiled program.
  87.  
  88.     -gas        Create output suitable for the GNU assembler. This is
  89.                 mainly useful to create code for other operating systems.
  90.  
  91.     -no-fp-return
  92.  
  93.                 Do not return floats and doubles in floating-point registers
  94.                 even if code for an fpu is generated. This is mainly useful
  95.                 to create code for other operating systems.
  96.  
  97.     -no-mreg-return
  98.  
  99.                 Do not use multiple registers to return types that do not
  100.                 fit into a single register. This is mainly for backwards
  101.                 compatibility.
  102.  
  103.     -d2scratch  obsolete
  104.  
  105.     -noa4       obsolete
  106.  
  107.  
  108. SOME INTERNALS
  109.  
  110.     The current version generates assembler output for use with the PhxAss
  111.     assembler (c) by Frank Wille. Most peephole optimizations are done by the
  112.     assembler so vbcc only does some that the assembler cannot make.
  113.     The generated executables will probably only work with OS2.0 or higher.
  114.  
  115.     With -gas assembler output suitable for the GNU assembler is generated
  116.     (the version must understand the Motorola syntax - some old ones do not).
  117.     The output is only slightly modified from the PhxAss-output and will
  118.     therefore result in worse code on gas. However this code generator should
  119.     be usable on most operating systems on 68k machines that way.
  120.  
  121.     The register names are:
  122.  
  123.          a0,  a1,  a2,  a3,  a4,  a5,  a6,  a7
  124.          d0,  d1,  d2,  d3,  d4,  d5,  d6,  d7
  125.         fp0, fp1, fp2, fp3, fp4, fp5, fp6, fp7
  126.  
  127.     The registers d0, d1, a0, a1, fp0 and fp1  are used as scratch registers
  128.     (i.e. they can be destroyed in function calls), all other registers are
  129.     preserved.
  130.  
  131.     All elementary types up to 4 bytes are returned in register d0 like
  132.     common on the Amiga (although I think pointers should better be returned
  133.     in a0). If compiled for an fpu, floating point values are returned in
  134.     fp0 unless -no-fpreturn is specified.
  135.     Types which are 8, 12 or 16 bytes large will be returned in several
  136.     registers (d0/d1/a0/a1) unless -no-mreg-return is specified.
  137.     All other types are returned by passing the function the address
  138.     of the result as a hidden argument - so when you call such a function
  139.     without a proper declaration in scope you can expect a crash.
  140.  
  141.     You must not link objects together that have been compiled with
  142.     different settings!
  143.  
  144.     vbcc uses d0-d7 and a0-a6 for temporary results and register variables
  145.     (a4 is used as small data pointer if -sd is used). a5 can be
  146.     used as frame pointer for automatic variables (but this is not necessary -
  147.     they can be accessed through a7, too). At the moment all local
  148.     variables are addressed via (dist,ax), so a function may have only ~32k
  149.     of local variables if code for <=68000 is generated.
  150.  
  151.     The elementary data types are represented like:
  152.  
  153.     type        size in bits        alignment in bytes
  154.  
  155.     char                8                       1
  156.     short              16                       2
  157.     int                32                       2
  158.     long               32                       2
  159.     all pointers       32                       2
  160.     float(fpu)         32                       2       see below
  161.     double(fpu)        64                       2       see below
  162.  
  163.     Although it would be better to have all 32bit+ types aligned to 4 bytes
  164.     I chose 2 bytes to be compatible with the Amiga system structures which
  165.     unfortunately have longwords aligned to 4n+2-addresses.
  166.  
  167.     The amiga68k code generator at the moment only works on systems
  168.     that store floats and doubles in a similar way (IEEE) like the Amiga.
  169.  
  170.  
  171. SMALL DATA
  172.  
  173.     vbcc can access static data in two ways. By default all such data will
  174.     be accessed with full 32bit addresses (large data model).
  175.     However there is a second way. You can set up an address register (a4)
  176.     to point into your data segment and then address data with a 16bit
  177.     offset through this register.
  178.     The advantages of the small data model are that your program will
  179.     usually be smaller (because the 16bit offsets use less space and no
  180.     relocation information is needed) and faster.
  181.     The disadvantages are that one address register cannot be used by the
  182.     compiler and that you can use it only if all your static data occupies
  183.     less than 64kb. Also you may not mix object modules and libraries that
  184.     have been compiled with different data models (you can call functions
  185.     compiled with large data model from object files compiled with small
  186.     data model, but not vice versa and only functions can be called that
  187.     way - other data cannot be accessed) and you probably have to use
  188.     PhxLnk then.
  189.  
  190.     If you use small data together with functions which are called from
  191.     functions which have not been compiled with vbcc or with the small data
  192.     model then you _must_ call geta4() as the first statement in your
  193.     function (do not use automatic initializations prior to the call to
  194.     geta4).
  195.     Note that you must not call geta4() through a function pointer!
  196.  
  197.  
  198. SMALL CODE
  199.  
  200.     If you use the small code model calls to external functions (i.e. from
  201.     libraries or other object files) are done with 16bit offsets over
  202.     the program counter rather than with absolute 32bit addresses.
  203.     The advantage is slightly smaller and faster code.
  204.     The disadvantages are that all the code (including library functions)
  205.     must be small enough and that you may have to use PhxLnk. However
  206.     you can link objects/libraries together if they have been compiled
  207.     with different code models.
  208.  
  209.  
  210. CPUs
  211.  
  212.     At the moment the values of -cpu=n have those effects:
  213.  
  214.     n>=68020:   - 32bit multiplication/division/modulo is done with the
  215.                   mul?.l, div?.l and div?l.l instructions
  216.                 - tst.l ax is used
  217.                 - extb.l dx is used
  218.                 - 16/32bit offsets are used in certain addressing modes
  219.                 - link.l is used
  220.                 - addressing modes with scaling are used
  221.                 - (dx) is used if no address register is available (not yet)
  222.  
  223.     n==68040    - 8bit constants are not copied in data registers
  224.  
  225.  
  226. FPUs
  227.  
  228.     At the moment the values of -fpu=n have those effects:
  229.  
  230.     n>68000:    - floating point calculations are done using the fpu
  231.     n=68040:
  232.     n=68060:    - instructions that have to be emulated on these fpus
  233.                   will not be used; at the moment this only includes
  234.                   the fintrz instruction in case of the 040
  235.  
  236.  
  237. MATH
  238.  
  239.     Integer math hopefully works without problems on all cpus. Long multiply
  240.     on cpus <68020 uses inline routines. This may increase code size a bit,
  241.     but it should be significantly faster, because function call overhead
  242.     is not necessary and the compiler can use the registers which already
  243.     contain the sources and/or need the result. However if anyone really
  244.     wants an option for using library routines for multiply, this can easily
  245.     be implemented. Long division and modulo is handled by calls to library
  246.     functions. At the moment standard library calls with parameter passing
  247.     via stack are used. This is rather slow, but division takes quite some
  248.     time anyway.
  249.     (mult/div/mod with constant powers of two are replaced by corresponding
  250.      bitwise operations (mod only if the other operand is unsigned), but
  251.      sums of powers of two not yet).
  252.  
  253.     If no FPU is specified floating point math is done using the C=
  254.     math libraries. 32 bit IEEE format is used for float and 64 bit IEEE
  255.     for double.
  256.  
  257.     Floating point math is done with the FPU if one is specified (see above).
  258.     Floating point values are kept in registers then and therefore may
  259.     have extended precision sometimes, which is not ANSI compliant (but
  260.     will usually cause no harm). When floating point values are stored in
  261.     memory they use the same IEEE formats as without FPU.
  262.     Float or double return values are passed in fp0.
  263.  
  264.     Note that you must not link object files together if they were not
  265.     compiled with the same -fpu settings and that you have to link with
  266.     the proper math library (see vclib.doc).
  267.  
  268.  
  269. STDARG
  270.  
  271.     A possible <stdarg,h> could look like this:
  272.  
  273.     typedef unsigned char *va_list;
  274.  
  275.     #define va_start(ap, lastarg) ((ap) = (va_list)(&lastarg + 1))
  276.     #define va_arg(ap, type) ((ap) += \
  277.       (sizeof(type)<sizeof(int)?sizeof(int):sizeof(type)), ((type *)(ap))[-1])
  278.     #define va_end(ap) ((ap) = 0L)
  279.  
  280.  
  281. KNOWN PROBLEMS
  282.  
  283.     - Converting floating point values to unsigned integers is not correct
  284.       if the value is >LONG_MAX and code for an FPU is generated.
  285.  
  286.     - The extended precision of the FPU registers can cause problems if
  287.       a program depends on the exact precision. Most programs will not
  288.       have trouble with that, but programs which do exact comparisons
  289.       with floating point types (e.g. to try to calculate the number
  290.       of significant bits) may not work as expected (especially if the
  291.       optimizer was turned on).
  292.  
  293.  
  294. Volker Barthelmann                                      volker@vb.franken.de
  295. Kennedy-Ring 39
  296. 91301 Forchheim
  297. Germany
  298.  
  299.